본문으로 건너뛰기

React의 렌더링 규칙

React의 렌더링은 내부적으로는 Fiber, Reconciler, Phase 같은 복잡한 구조로 이루어져 있습니다. 하지만 개발자가 매일 마주하는 것은 그 내부 구현이 아니라 “어떤 조건에서 컴포넌트가 다시 렌더링되는가”라는 규칙이다.

이 글에서는 React가 렌더링을 전파하고, 어떤 변경을 렌더링의 트리거로 삼는지, 그리고 이 규칙들이 왜 이런 형태로 설계되었는지를 정리해보려고 합니다.


렌더링을 다시 한다는 말의 진짜 의미

React에서 말하는 렌더링은 DOM을 직접 그리는 행위가 아니다. 컴포넌트 함수를 다시 실행해서 새로운 React Element 트리를 만드는 과정이다.


state가 바뀌면 항상 리렌더링될까?

결론부터 말하면 setState가 호출되면 렌더링은 예약된다. 값이 같아 보여도 참조가 달라지면 React는 변경으로 인식한다.

setCount(1);
setCount(1); // 여전히 렌더링 예약됨

props가 바뀌지 않았는데 왜 다시 렌더링될까?

부모가 렌더링되면 기본적으로 자식도 다시 렌더링된다. React는 기본적으로 부모-자식 전파 모델을 따른다.


부모 리렌더링과 자식 리렌더링 전파

이 구조 덕분에 React는 복잡한 의존성 그래프 없이도 UI 일관성을 유지할 수 있다.


Context 변경이 렌더링에 미치는 영향

Context는 구독 모델이다. 값이 변경되면 해당 Context를 사용하는 모든 컴포넌트가 렌더링된다.


StrictMode에서 렌더링이 두 번 일어나는 이유

개발 환경에서만 발생하며, 사이드 이펙트를 조기에 발견하기 위한 의도적인 동작이다.


렌더링과 DOM 업데이트는 왜 다른가

렌더링은 계산 단계, DOM 업데이트는 커밋 단계다.

모든 렌더링이 DOM 변경으로 이어지지는 않는다.


정리

React 렌더링을 바라보는 올바른 관점

  • 렌더링은 비용이 아니라 전제다
  • DOM 변경이 진짜 비용이다
  • 불변성과 참조 비교가 여기서 의미를 가진다